Metoda przeprowadzania audytu architektury w zasadzie jest bardzo prosta, ogólna i składa się z kilku kroków:
- Definicja celu audytu
- Ustalenie obszarów objętych badaniem i konkretyzacja kryteriów
- Przgotowanie narzędzi pracy (o tym w kolejnych artykułach)
- Właściwe badanie architektury
- Opracowanie zebranych danych (w tym ocena aktualnej architektury)
- Sfomułowanie propozycji działań, ewentualnie konkretnych kroków, prowadzących do poprawy obecnej sytuacji
Bardzo ważne jest przy tym konkretne zdefiniowanie celu audytu, ponieważ to pociąga za sobą dobór obszarów badania i narzędzi. Owe obszary badania, jak napisałem, mogą się zmieniać od adytu do audytu. Poniżej krótkie zestawienie tych, które wydają mi się na tyle uniwersalne, że warto się nad nimi zastanowić w niemal każdym projekcie.
- Procesy biznesowe: ich definicja i dokumentacja
- Architektura biznesowa: modularyzacja, interfejsy i obiekty przenoszące dane (nie tylko encje bazodanowe!)
- Architektura oprogramowania: techniczna definicja modułów, obiektów, interfejsów oraz obiektów danych
- Implementacja: użycie konstrukcji jęzka programowania, wzorce i antywzorce, dobre i złe praktyki
- Procesy w obrębie projektu: sprawdzenie, czy wszelkie artefakty opisujące tworzenie oprogramowania w konkretnym projekcie są tak samo rozumiane przez wszystkich zainteresowanych, sprawdzenie ciągłości procesów i ich definicji
- Dokumentacja: aktualność, kompletność, dostępność i jakość dokumentacji
- Porównanie z istniejącym (meta)modelem architektury
W kolejnych artykułach napiszę o przykładowych narzędziach, które stosowałem w audycie.