Dyrektor techniczny platformy e-commerce dla klientów biznesowych ma przed sobą trzy liczby. Czas od zgłoszenia do wdrożenia średniej zmiany wydłużył się w ciągu roku mniej więcej dwukrotnie. Rachunek za chmurę rośnie szybciej niż liczba zamówień. A zarząd chce za dwa kwartały wejść na rynek niemiecki z nowym modelem cenowym, który dotyka koszyka, rozliczeń, integracji z ERP i magazynem. Zespół ma na to trzy pomysły: wydzielić rozliczenia do osobnej usługi, przepisać całość na mikroserwisy albo „posprzątać” monolit i nic nie zmieniać w strukturze. Każdy pomysł ma swoich zwolenników, a każdy kosztuje inaczej.
CTO wie, że nie rozstrzygnie tego sporu na spotkaniu. Zespół jest za blisko systemu, każdy ma swoje ulubione rozwiązanie, a część decyzji, które dziś bolą, podjęli ludzie siedzący przy tym samym stole. Potrzebuje kogoś z zewnątrz, kto w krótkim czasie przeczyta system, porozmawia z ludźmi i powie, co w architekturze rzeczywiście jest ryzykiem, co jest tylko niewygodne i która z trzech dróg ma sens przy danym budżecie i terminie.
Ten artykuł jest dla CTO albo lidera technicznego, który rozważa zamówienie takiego audytu. Opisujemy, czym audyt architektury różni się od audytu kodu i od wewnętrznego przeglądu, co obejmuje jego zakres, jak przebiega, co powinno trafić do raportu, od czego zależy cena i co zapisać w umowie. Jeśli Twoje pytanie dotyczy kodu napisanego z asystentami AI, mamy na ten temat osobny artykuł; tutaj skupiamy się na strukturze systemu niezależnie od tego, kto i czym ją zbudował.
Czym audyt architektury różni się od audytu kodu i od wewnętrznego przeglądu?
Audyt kodu i audyt architektury patrzą na ten sam system z dwóch wysokości. Audyt kodu sprawdza jakość implementacji: czytelność, duplikację, pokrycie testami, obsługę błędów, bezpieczeństwo zależności. Audyt architektury sprawdza strukturę: jak system jest podzielony na komponenty, jak te komponenty od siebie zależą, jak płyną dane, jak wyglądają integracje i infrastruktura, i co te decyzje oznaczają dla skalowalności, niezawodności, bezpieczeństwa i kosztu zmian. Dobry kod w złej architekturze jest jak porządnie wykończone pokoje w budynku bez klatki schodowej. Zła architektura z dobrym kodem zwykle zdradza się tym, że każda zmiana wymaga dotknięcia wielu miejsc naraz.
W praktyce obie perspektywy się przenikają. Nie da się rzetelnie ocenić architektury bez czytania kodu w ścieżkach krytycznych, bo diagramy często opisują system, jaki miał powstać, a nie ten, który działa. Dlatego audyt kondycji kodu w ARDURA Consulting obejmuje jednocześnie przegląd kodu i ocenę architektury. Jeśli chcesz zobaczyć, jak taki audyt wygląda od strony kodu, zwłaszcza gdy powstawał z asystentami AI, opisaliśmy to w artykule audyt kodu z AI w 2 tygodnie. Tutaj patrzymy wyżej: na decyzje strukturalne i ich koszt.
Drugie rozróżnienie to audyt zewnętrzny a wewnętrzny przegląd architektury. Przegląd wewnętrzny prowadzi własny zespół, regularnie, na bazie listy przyszłych zmian i kryteriów jakości. To dobra praktyka i opisaliśmy ją szczegółowo w artykule o przeglądzie architektury oprogramowania. Audyt zewnętrzny ma inny cel: daje niezależną ocenę, gdy zespół jest stroną sporu, gdy decyzja jest droga, gdy trzeba ją uzasadnić wobec zarządu albo inwestora, albo gdy po prostu nikt w zespole nie ma doświadczenia z systemem tej skali. Oba podejścia się uzupełniają: dobry audyt kończy się zaleceniem, jak prowadzić regularne przeglądy wewnętrzne.
Kiedy CTO powinien zamówić zewnętrzny audyt architektury?
Audyt architektury opłaca się, gdy od struktury systemu zależy decyzja, za którą stoją realne pieniądze. Sytuacji jest kilka i warto je rozpoznać, bo każda ustawia nieco inny zakres.
Przed dużą przebudową. Zespół proponuje migrację do mikroserwisów, przepisanie modułu albo zmianę bazy danych. To decyzje warte setki tysięcy złotych i miesiące pracy. Audyt odpowiada na pytanie, czy problem, który ma rozwiązać przebudowa, rzeczywiście leży w architekturze, i czy proponowana zmiana go rozwiąże.
Przed skokiem skali. Nowy rynek, duży klient, kampania, która ma pomnożyć ruch. Pytanie brzmi: co pęknie pierwsze i ile kosztuje przygotowanie. Tu kluczowe są skalowalność, wydajność i infrastruktura.
Po przejęciu systemu. Nowy CTO, nowy dostawca albo przejęcie firmy. Trzeba wiedzieć, co się dostało, zanim zobowiąże się do roadmapy.
Gdy koszty rosną bez wyjaśnienia. Rachunek za chmurę rośnie szybciej niż ruch, czas wdrożenia zmian się wydłuża, liczba incydentów rośnie. Te objawy mają często przyczynę strukturalną, której nie widać z poziomu pojedynczych zgłoszeń.
Przed inwestycją albo transakcją. Inwestor lub kupujący chce wiedzieć, czy technologia udźwignie plan biznesowy. To zakres zbliżony do technical due diligence, z większym naciskiem na zespół, proces i ryzyka dla wartości transakcji.
Kiedy audyt to wyrzucone pieniądze? Gdy decyzja już zapadła i nikt nie zamierza jej zmienić; wtedy audyt jest kosztownym potwierdzeniem. Gdy system jest prototypem, który i tak zostanie przepisany. I gdy nikt nie zajmie się wnioskami. Przed zamówieniem zapisz decyzję, którą audyt ma wesprzeć, i osobę, która będzie właścicielem planu działań. Jeśli nie umiesz tego zrobić, nie jesteś jeszcze gotowy na audyt.
Co obejmuje zakres audytu architektury?
Zakres powinien wynikać z pytania, na które audyt ma odpowiedzieć, ale większość audytów dotyka tych samych obszarów. Punktem odniesienia są uznane modele jakości. Norma ISO/IEC 25010:2023 definiuje model jakości produktu z dziewięcioma cechami, wśród których są między innymi niezawodność, bezpieczeństwo, utrzymywalność i wydajność. AWS Well-Architected Framework opisuje sześć filarów: doskonałość operacyjną, bezpieczeństwo, niezawodność, efektywność wydajnościową, optymalizację kosztów i zrównoważony rozwój (AWS). Żaden z tych modeli nie jest listą kontrolną do odhaczenia, ale pomagają upewnić się, że audyt niczego istotnego nie pomija.
W praktyce zakres obejmuje zwykle siedem obszarów.
Struktura i zależności. Podział na moduły, usługi lub warstwy, kierunek zależności, granice odpowiedzialności, miejsca, w których zmiana w jednym komponencie wymusza zmiany w wielu innych. To tutaj najczęściej leży przyczyna wydłużającego się czasu wdrożenia zmian.
Dane. Model danych, własność danych między komponentami, spójność, migracje, kopie zapasowe i ich odtwarzanie. Rozproszone źródła prawdy dla tych samych danych to jeden z najdroższych problemów do naprawy później.
Integracje. Interfejsy z systemami zewnętrznymi i wewnętrznymi, obsługa błędów i ponowień, zależność od dostępności partnerów, wersjonowanie API.
Skalowalność i wydajność. Gdzie są wąskie gardła, co się stanie przy wielokrotnie większym ruchu, które elementy skalują się poziomo, a które nie. Tu przydaje się dostęp do monitoringu i, jeśli to możliwe, profilowanie wydajności.
Niezawodność i operacje. Pojedyncze punkty awarii, monitoring, alerty, sposób wdrażania, czas odtworzenia po awarii, plan ciągłości działania.
Bezpieczeństwo architektury. Granice zaufania, uwierzytelnianie i autoryzacja między komponentami, zarządzanie sekretami, segmentacja sieci, przegląd bezpieczeństwa zależności. To nie jest test penetracyjny działającego systemu, tylko ocena, czy struktura sprzyja bezpieczeństwu.
Koszt zmian i dług technologiczny. Ile kosztuje dziś dodanie typowej funkcji, gdzie leży dług, ile kosztuje jego obsługa w codziennej pracy i czego wymagałaby spłata. Ten obszar łączy pozostałe z językiem zarządu.
Przy pytaniach inwestorskich albo przy dużym skoku skali do zakresu dochodzą zespół i proces wytwarzania, infrastruktura w szerszym ujęciu i zgodność licencji open source. To już zakres technical due diligence. Ogólne pojęcia porządkuje nasze hasło o architekturze oprogramowania.
Czego audyt architektury nie zrobi?
Równie ważne jak zakres są jego granice, bo od nich zależą oczekiwania zarządu. Audyt architektury nie zastąpi czterech innych prac, które czasem się z nim myli.
Nie jest testem penetracyjnym. Ocenia, czy struktura sprzyja bezpieczeństwu, i przegląda bezpieczeństwo kodu oraz zależności, ale nie atakuje działającego systemu z zewnątrz. Jeśli potrzebujesz potwierdzenia, że podatności nie da się wykorzystać, zamów pentest osobno, najlepiej po audycie, gdy wiesz, gdzie szukać.
Nie jest testem obciążeniowym. Może wskazać wąskie gardła na podstawie kodu, konfiguracji i danych z monitoringu, ale nie zmierzy, przy jakim ruchu system faktycznie się zatrzyma. Jeśli od tej liczby zależy decyzja, zaplanuj testy wydajnościowe jako kolejny krok.
Nie jest projektem docelowej architektury. Audyt mówi, co jest ryzykiem, co trzeba zmienić i w jakiej kolejności, a przy sporze o kierunek porównuje opcje. Szczegółowy projekt docelowy, z kontraktami interfejsów i planem migracji danych, to osobna praca, którą lepiej zlecić po decyzji, a nie przed nią.
Nie jest oceną ludzi. Audyt opisuje decyzje i ich skutki, a nie kompetencje poszczególnych osób. Przy technical due diligence ocenia zespół i proces jako całość, ale celem nie jest wskazanie winnych. Zespół, który usłyszy na starcie, że audyt szuka winnych, przestanie mówić prawdę, a bez tej prawdy raport jest wart mniej.
Jakie metody stosuje się w audycie architektury?
Rzetelny audyt łączy kilka metod, bo każda widzi co innego. Warto zapytać dostawcę, których używa i w jakich proporcjach.
Przegląd dokumentacji i odtworzenie modelu. Audytor zbiera istniejące diagramy, opisy i decyzje, a tam, gdzie ich brakuje, odtwarza model z kodu i konfiguracji. Popularnym sposobem zapisu jest model C4 Simona Browna, który opisuje system na czterech poziomach: kontekstu, kontenerów, komponentów i kodu (c4model.com). Odtworzony model bywa jednym z najcenniejszych produktów audytu, bo zespół często pierwszy raz widzi system w całości.
Analiza statyczna i analiza zależności. Narzędzia pokazują strukturę zależności między modułami, cykle, miejsca o wysokiej złożoności i często zmieniane pliki. Same w sobie generują dużo szumu, dlatego ich wynik jest punktem wyjścia do ręcznego przeglądu, a nie wnioskiem.
Ręczny przegląd ścieżek krytycznych. Doświadczeni inżynierowie czytają kod i konfigurację w miejscach, które decydują o biznesie: płatności, rozliczenia, autoryzacja, główne integracje. To tu odróżnia się realne ryzyko od teoretycznego.
Scenariusze jakościowe. Zamiast pytać ogólnie „czy system jest skalowalny”, audyt formułuje konkretne scenariusze: „ruch rośnie pięciokrotnie w ciągu godziny”, „partner zmienia format API”, „trzeba dodać nową walutę”. Dla każdego scenariusza ocenia, jak architektura się zachowa i ile kosztuje dostosowanie. To podejście wywodzi się z metody ATAM (Architecture Tradeoff Analysis Method) opracowanej w Software Engineering Institute na Carnegie Mellon University, która ocenia architekturę względem celów jakościowych i ujawnia kompromisy między nimi. Pełna ewaluacja ATAM według SEI trwa zwykle trzy do czterech dni i angażuje szerokie grono interesariuszy (SEI); audyty komercyjne często stosują jej lżejszą wersję.
Rozmowy z zespołem. Krótkie rozmowy z architektem, liderami zespołów i osobą odpowiedzialną za utrzymanie wyjaśniają, dlaczego system wygląda tak, a nie inaczej, i jakie ograniczenia były wtedy realne. Bez nich audytor ocenia decyzje bez kontekstu, a raport staje się listą zarzutów.
Dane operacyjne. Metryki z monitoringu, historia incydentów, rachunki za chmurę, dane o wdrożeniach. Program badawczy DORA opisuje pięć miar wydajności dostarczania oprogramowania, w tym czas realizacji zmiany, częstotliwość wdrożeń i odsetek zmian kończących się awarią (DORA). Jeśli je mierzysz, audyt może powiązać problemy strukturalne z liczbami, które zarząd rozumie.
Jak przebiega audyt architektury tydzień po tygodniu?
Przebieg zależy od wielkości systemu i pakietu, ale ma powtarzalną strukturę. Poniżej przykład dla dwutygodniowego audytu systemu z kilkoma usługami i kilkoma integracjami.
Przed startem: NDA, zakres, dostępy. Podpisanie NDA, uzgodnienie pytań, na które audyt ma odpowiedzieć, i granic zakresu. Nadanie dostępu tylko do odczytu do repozytoriów, dokumentacji i, jeśli to potrzebne, konfiguracji infrastruktury oraz monitoringu. Ustalenie terminów rozmów z zespołem.
Dni 1–3: model i skany. Odtworzenie modelu systemu z dokumentacji, kodu i konfiguracji. Analiza statyczna i analiza zależności na całym kodzie. Pierwsza lista hipotez: gdzie mogą leżeć problemy strukturalne.
Dni 4–7: przegląd ręczny i rozmowy. Czytanie ścieżek krytycznych, weryfikacja hipotez, rozmowy z zespołem. Przegląd danych operacyjnych i kosztów infrastruktury. Scenariusze jakościowe dla kluczowych pytań, na przykład skoku ruchu albo nowej funkcji, która dotyka wielu komponentów.
Dni 8–9: synteza. Mapa ryzyk ocenionych według wpływu na biznes, oszacowanie długu technologicznego, priorytety i plan działań. Jeśli audyt ma rozstrzygnąć spór o kierunek, na przykład przebudowę, tu powstaje porównanie opcji z kosztami i ryzykami.
Dzień 10: raport i spotkanie podsumowujące. Pisemny raport i omówienie z decydentami, z czasem na pytania przed podjęciem działań.
W wariancie trzytygodniowym, typowym dla technical due diligence, dochodzi ocena zespołu i procesu wytwarzania, szersza ocena infrastruktury i skalowalności oraz zgodności licencji open source, a raport jest pisany tak, żeby mogli go przeczytać inwestorzy i zarząd bez przygotowania technicznego.
Co powinien zawierać raport z audytu architektury?
Raport jest produktem, za który płacisz, więc warto wiedzieć z góry, jak ma wyglądać. Dobry raport z audytu architektury ma pięć części.
Podsumowanie dla decydentów. Jedna, dwie strony: odpowiedź na pytanie, które postawiłeś na starcie, najważniejsze ryzyka i rekomendacja. Jeśli prezes nie zrozumie tej części bez pomocy, raport jest napisany dla audytora, a nie dla Ciebie.
Model systemu. Aktualny obraz architektury, zwykle na dwóch lub trzech poziomach szczegółowości. Często pierwszy aktualny diagram w historii systemu.
Mapa ryzyk. Ustalenia pogrupowane według obszarów, czyli struktury, danych, integracji, skalowalności, niezawodności, bezpieczeństwa i kosztu zmian, i ocenione według wpływu na biznes i prawdopodobieństwa. Każde ustalenie z konkretnym odwołaniem do komponentu, pliku albo konfiguracji, a nie ogólnikiem.
Oszacowanie długu technologicznego. Gdzie leży, ile kosztuje w codziennej pracy i czego wymagałaby jego spłata, w przedziałach, nie w jednej liczbie.
Priorytety i plan działań. Wyraźny podział na to, co trzeba naprawić od razu, co może poczekać do kolejnego kwartału, a co można świadomie zaakceptować. Konkretne kroki we właściwej kolejności, tak żeby Twój zespół, nowy dostawca albo zewnętrzny zespół mogli zacząć pracę tydzień po spotkaniu podsumowującym. Jeśli audyt miał rozstrzygnąć wybór kierunku, raport porównuje opcje z kosztami, ryzykami i warunkami, przy których każda ma sens.
Uważaj na raporty złożone głównie z wykresów z narzędzi i setek ostrzeżeń bez priorytetów. Takie raporty są łatwe do wyprodukowania i bezużyteczne przy podejmowaniu decyzji. Poproś przed podpisaniem umowy o zanonimizowaną próbkę albo przynajmniej spis treści.
Ile kosztuje audyt architektury i od czego zależy cena?
Nie ma wiarygodnego publicznego cennika rynkowego audytów architektury, który dałoby się uczciwie zacytować. Podajemy więc dwie rzeczy: nasze własne ceny, które da się sprawdzić, i czynniki, które przesuwają cenę u każdego dostawcy.
W ARDURA Consulting ocena architektury nie jest osobnym produktem, tylko częścią dwóch pakietów o stałym zakresie, opisanych na stronie audytu kodu i technical due diligence:
- Audyt kondycji kodu (Code Health Audit): od 18 000 PLN, 1–2 tygodnie. Zakres: przegląd kodu i analiza statyczna, ocena architektury, profilowanie wydajności, przegląd bezpieczeństwa kodu i zależności, oszacowanie długu technologicznego. Rezultat: raport z mapą ryzyk i priorytetowym planem naprawczym.
- Technical Due Diligence: od 35 000 PLN, 2–3 tygodnie. Zakres: wszystko z audytu kondycji kodu plus zespół i proces wytwarzania, skalowalność i infrastruktura, zgodność licencji open source, ryzyka istotne dla inwestora lub kupującego. Rezultat: raport dla inwestora i spotkanie podsumowujące z decydentami.
Ostateczna cena zależy od wielkości systemu i jest ustalana przed rozpoczęciem prac, więc nie rośnie w trakcie. Jeśli Twoje pytanie dotyczy głównie struktury, długu i kosztu zmian, zwykle wystarcza pierwszy pakiet. Jeśli dotyczy skalowalności, infrastruktury i zespołu albo stoi za nim inwestor, właściwy jest drugi.
U każdego dostawcy cenę przesuwają te same czynniki. Poniższa tabela pomaga dobrać zakres do pytania.
| Twoje pytanie | Obszary, które muszą być w zakresie | Pakiet w ARDURA | Typowy czas | Co przesuwa cenę w górę |
|---|---|---|---|---|
| Dlaczego zmiany trwają coraz dłużej i ile nas to kosztuje? | Struktura i zależności, dług technologiczny, ścieżki krytyczne | Audyt kondycji kodu | 1–2 tygodnie | Liczba repozytoriów i języków, wielkość monolitu |
| Czy przebudowa (np. wydzielenie usług) ma sens? | Struktura, dane, integracje, scenariusze zmian, porównanie opcji | Audyt kondycji kodu, czasem z rozszerzeniem | 2 tygodnie | Liczba porównywanych opcji, rozproszenie danych |
| Czy system udźwignie wielokrotny wzrost ruchu? | Skalowalność, wydajność, infrastruktura, niezawodność | Technical Due Diligence | 2–3 tygodnie | Złożoność infrastruktury, brak monitoringu, potrzeba testów obciążeniowych |
| Co przejmujemy od odchodzącego dostawcy? | Struktura, dokumentacja, dług, bezpieczeństwo, proces | Audyt kondycji kodu lub Technical Due Diligence | 1–3 tygodnie | Brak dokumentacji, brak dostępu do osób, które budowały system |
| Czy technologia udźwignie plan inwestora? | Wszystko powyżej plus zespół, proces, licencje open source | Technical Due Diligence | 2–3 tygodnie | Liczba produktów, wymagania regulacyjne, termin transakcji |
| Dlaczego rachunek za chmurę rośnie szybciej niż ruch? | Infrastruktura, struktura, wydajność, dane operacyjne | Technical Due Diligence | 2–3 tygodnie | Liczba kont i środowisk, brak tagowania kosztów |
Zwróć uwagę na dwie rzeczy, które cenę obniżają. Pierwsza to dobre przygotowanie: zebrana dokumentacja i zarezerwowany czas ludzi skracają audyt bardziej niż jakikolwiek rabat. Druga to precyzyjne pytanie. Audyt „całego systemu na wszelki wypadek” kosztuje więcej i daje mniej niż audyt, który ma odpowiedzieć na jedno konkretne pytanie.
Jak ustalić zakres, żeby audyt nie rozrósł się do budżetu?
Audyt architektury to praca zamknięta, ale tylko wtedy, gdy zakres jest zapisany precyzyjnie. Cztery zasady pomagają go utrzymać.
Zacznij od decyzji, nie od systemu. Zapisz jednym zdaniem, jaką decyzję ma wesprzeć audyt. „Czy wydzielamy rozliczenia do osobnej usługi przed wejściem na nowy rynek?” daje zupełnie inny zakres niż „oceńcie naszą architekturę”.
Nazwij granice. Które komponenty, repozytoria i środowiska są w zakresie, a które nie. Jeśli system ma moduł, którego nikt nie zamierza ruszać przez dwa lata, nie płać za jego szczegółowy przegląd.
Ustal poziom szczegółowości wniosków. Czy potrzebujesz rekomendacji kierunku z szacunkiem w przedziałach, czy projektu docelowej architektury? To drugie jest osobną pracą, zwykle po audycie, a nie jego częścią.
Zapisz, co się dzieje, gdy audyt znajdzie coś poza zakresem. Na przykład krytyczną lukę bezpieczeństwa w module wyłączonym z audytu. Dobra praktyka: audytor zgłasza to od razu, nie analizuje szczegółowo, a decyzję o rozszerzeniu podejmujesz Ty.
Dla przykładu, dobrze zapisany zakres dla platformy z wprowadzenia mógłby brzmieć tak: „Audyt ma rozstrzygnąć, czy przed wejściem na nowy rynek wydzielić moduł rozliczeń do osobnej usługi, czy uporządkować go w obecnym monolicie. W zakresie: repozytorium głównej aplikacji, moduły koszyka, rozliczeń i cenników, integracja z ERP i magazynem, konfiguracja infrastruktury i dane kosztowe chmury z ostatnich sześciu miesięcy. Poza zakresem: panel administracyjny i aplikacja mobilna. Wynik: mapa ryzyk, porównanie dwóch opcji z kosztem i ryzykiem, rekomendacja i plan pierwszych kroków.” Taki opis da się wycenić, zrealizować w ustalonym czasie i rozliczyć przy odbiorze.
Jeśli nie wiesz jeszcze, jak sformułować pytanie, pomocna jest nasza bezpłatna lista kontrolna długu technologicznego: 42 pytania tak/nie w siedmiu obszarach systemu. Odpowiedzi często pokazują, gdzie leży problem, i pozwalają zawęzić zakres audytu.
Czego audytor potrzebuje od Twojego zespołu?
Audyt jest szybki tylko wtedy, gdy audytor nie czeka na dostęp i ludzi. Przygotuj cztery rzeczy.
Dostępy tylko do odczytu. Repozytoria kodu, dokumentacja, konfiguracja infrastruktury jako kod, jeśli istnieje, monitoring i logi. Dostęp do środowisk testowych lub produkcyjnych jest opcjonalny, ale pomaga przy wnioskach o wydajności. Uprawnienia do zapisu nie są potrzebne.
Dokumentację, jaka by nie była. Diagramy, nawet nieaktualne, zapisy decyzji architektonicznych, opisy integracji, historia incydentów, notatki z wdrażania nowych osób. „Nie mamy dokumentacji” to też wniosek, ale wszystko, co macie, oszczędza czas.
Czas właściwych osób. Trzy lub cztery rozmowy po pół godziny do godziny: z architektem lub najstarszym stażem inżynierem, z liderami zespołów, z osobą odpowiedzialną za utrzymanie i wdrożenia, czasem z właścicielem produktu.
Dane operacyjne i kosztowe. Metryki z monitoringu, dane o wdrożeniach, rachunki za chmurę z ostatnich miesięcy. Bez nich wnioski o wydajności i koszcie są oparte na przypuszczeniach.
Co zapisać w umowie z audytorem architektury?
Umowa na audyt jest krótka, ale kilka zapisów chroni Cię przed typowymi problemami.
NDA przed dostępem. Poufność podpisana przed nadaniem jakiegokolwiek dostępu do kodu, dokumentacji czy systemów.
Stały zakres, termin i cena. Pytania, na które audyt odpowiada, granice zakresu, czas trwania i cena ustalone na piśmie przed startem. Jeśli dostawca nie potrafi ich ustalić, audyt rozrośnie się do budżetu.
Lista produktów. Raport z wymienionymi częściami, model systemu, spotkanie podsumowujące. Najlepiej z próbką albo spisem treści jako załącznikiem.
Prawa do raportu. Raport i plan działań należą do Ciebie, z prawem udostępnienia ich zarządowi, inwestorom i innym dostawcom.
Niezależność. Zapis, że audyt nie zobowiązuje Cię do dalszej współpracy z audytorem. Jeśli audytor oferuje też realizację planu, to w porządku, ale decyzja o tym, kto go wykona, należy do Ciebie.
Dostęp tylko do odczytu i zasady bezpieczeństwa. Zakres uprawnień, sposób przechowywania danych audytu, usunięcie kopii po zakończeniu.
Jakie są czerwone flagi przy wyborze dostawcy audytu?
Zadaj kilka pytań przed podpisaniem umowy, niezależnie od tego, kogo wybierzesz.
Kto czyta kod i konfigurację? Narzędzia to oczywistość. Zapytaj, jaka część pracy to ręczny przegląd przez doświadczonych inżynierów i jak wybierają, co czytać. Dostawca, który sprzedaje wynik narzędzia z logo na okładce, sprzedaje Ci setki ostrzeżeń bez priorytetów.
Czy dostawca ma gotową odpowiedź przed audytem? Jeśli już na pierwszym spotkaniu słyszysz, że „trzeba przejść na mikroserwisy” albo „wszystko do chmury X”, audyt potwierdzi tezę, a nie ją sprawdzi.
Jak wygląda raport? Poproś o próbkę. Szukaj podsumowania dla decydentów, ocen według wpływu na biznes, uszeregowanego planu i konkretnych odwołań do komponentów.
Czy zakres i cena są stałe? Audyt to praca zamknięta. Wycena „od godziny” bez limitu to sygnał, że dostawca sam nie wie, co zrobi.
Co się stanie, jeśli znajdą coś, czego nie naprawisz sam? Dobry dostawca przedstawi opcje, łącznie ze współpracą z kimś innym. Dostawca, którego audyt zawsze kończy się wnioskiem, że potrzebujesz jego zespołu na rok, sprzedaje lejek sprzedażowy, a nie audyt.
Co zrobić z wynikami audytu architektury?
Raport sam niczego nie zmienia. Wartość audytu powstaje w tygodniach po spotkaniu podsumowującym, a pierwsze kroki warto zaplanować jeszcze przed jego zakończeniem.
Przypisz właścicieli pierwszych działań na spotkaniu podsumowującym. Trzy najważniejsze pozycje z planu powinny mieć właściciela i termin, zanim wszyscy wyjdą z sali.
Zamień rekomendacje w decyzje zapisane jako ADR. Każda rekomendacja, którą przyjmujesz albo odrzucasz, powinna trafić do rejestru decyzji architektonicznych: kontekst, decyzja, status, konsekwencje. Za rok będzie wiadomo, dlaczego system wygląda tak, a nie inaczej.
Wpisz dług do planowania. Ustal, jaka część pojemności zespołu idzie na spłatę długu wskazanego w audycie, i mierz postęp. Bez tego dług przegra z każdą nową funkcją.
Ustaw regularne przeglądy wewnętrzne. Audyt zewnętrzny to zdjęcie w jednym momencie. Wewnętrzne przeglądy, opisane w artykule o przeglądzie architektury oprogramowania, utrzymują jakość między audytami.
Zdecyduj, kto realizuje plan. Twój zespół, inny dostawca albo ARDURA. Jeśli audyt pokaże, że system wymaga stabilizacji albo zmiany dostawcy, możemy kontynuować w ramach Software Rescue, zaczynając od priorytetów ustalonych w audycie. Objawy, które zwykle do tego prowadzą, opisaliśmy w artykule o siedmiu sygnałach, że aplikację trzeba ratować. Więcej tekstów o budowie i rozwoju systemów znajdziesz w hubie software development.
Kiedy powtórzyć audyt?
Audyt zewnętrzny nie musi być corocznym rytuałem. Sensowne momenty na kolejny to: zakończenie dużej przebudowy, którą audyt rekomendował, żeby sprawdzić, czy przyniosła oczekiwany efekt; kolejna decyzja o podobnej skali, na przykład następny rynek albo nowa linia produktów; zmiana dostawcy albo kluczowych osób w zespole; oraz sytuacja, w której wskaźniki, które audyt pomógł ustawić, przestają się poprawiać. Drugi audyt jest zwykle krótszy i tańszy od pierwszego, bo model systemu, rejestr decyzji i lista ryzyk już istnieją.
Podsumowanie: jak zamówić audyt architektury, który pomoże podjąć decyzję?
Audyt architektury nie jest oceną zespołu ani konkursem na najładniejszy diagram. Odpowiada na węższe i bardziej praktyczne pytanie: co w strukturze systemu jest realnym ryzykiem dla biznesu, ile kosztuje i co zrobić najpierw. Najlepiej działa, gdy stoi za nim konkretna decyzja, a najgorzej, gdy zamawia się go „na wszelki wypadek”.
Zapamiętaj pięć rzeczy. Po pierwsze, zapisz decyzję, którą audyt ma wesprzeć, i osobę odpowiedzialną za plan działań. Po drugie, dobierz zakres do pytania: struktura i dług to zwykle audyt kondycji kodu, skalowalność, infrastruktura i zespół to technical due diligence. Po trzecie, wymagaj metod, które łączą narzędzia z ręcznym przeglądem, rozmowami i scenariuszami jakościowymi. Po czwarte, ustal zakres, termin i cenę na piśmie przed startem; w ARDURA audyt kondycji kodu zaczyna się od 18 000 PLN, a technical due diligence od 35 000 PLN. Po piąte, zaplanuj, co zrobisz z wynikami, zanim raport trafi na Twoje biurko.
Jeśli stoisz przed decyzją o przebudowie, skoku skali albo przejęciu systemu, zobacz pakiety audytu kodu i technical due diligence albo umów rozmowę o zakresie. W pół godziny powiemy, który pakiet pasuje do Twojego pytania, ile będzie kosztował i czy w ogóle potrzebujesz audytu.