Każdy system ma złożoność. Część wynika z problemu, który rzeczywiście trzeba obsłużyć, a część z decyzji technicznych, dodatkowych integracji i funkcji dokładanych „na wszelki wypadek”. Architektura bez nadmiaru polega na tym, aby odróżniać te dwie rzeczy i utrzymywać rdzeń możliwie czytelnym.
Złożoność potrzebna i złożoność przypadkowa
Potrzebna złożoność to na przykład różne role użytkowników, historia zmian, wymagania prawne albo komunikacja z urządzeniem. Przypadkowa złożoność pojawia się, gdy system ma kilka sposobów wykonania tej samej czynności, przechowuje dane w wielu miejscach bez powodu lub zależy od modułów, których nikt nie używa.
Pięć pytań przed dodaniem warstwy
- Jaki konkretny problem rozwiązuje ta warstwa?
- Czy można osiągnąć ten sam cel prostszą funkcją?
- Kto będzie ją utrzymywał po wdrożeniu?
- Jak zmieni się czas odpowiedzi, koszt i bezpieczeństwo?
- Jak usuniemy ją w przyszłości, jeśli proces się zmieni?
Jeżeli na te pytania nie ma odpowiedzi, decyzja nie powinna być automatyczna. Dokumentowanie powodów jest tak samo ważne jak sam wybór technologii.
Rdzeń, granice i rozszerzenia
Dobrze zbudowany system ma stabilny rdzeń: użytkowników, dane główne, podstawowe reguły i najważniejsze przepływy. Integracje oraz raporty mogą być dołączane przez jasno określone granice. Dzięki temu rozwój nie wymaga przepisywania wszystkiego, ale też nie pozwala każdemu dodatkowi zmieniać zachowania całego systemu.
W praktyce: każda funkcja powinna mieć właściciela biznesowego. Jeśli nikt nie potrafi powiedzieć, kto jej potrzebuje i jak oceni jej działanie, to prawdopodobnie jest jeszcze za wcześnie na implementację.
Prostota obniża koszt zmian
Największą wartość widać nie w dniu uruchomienia, lecz przy pierwszej zmianie procesu. Czy można dodać pole bez ryzyka dla raportów? Czy nowa osoba rozumie ekran po krótkim szkoleniu? Czy da się odtworzyć, dlaczego system podjął decyzję? Odpowiedzi zależą od architektury i jakości granic, nie od liczby użytych narzędzi.
W Utilite Bronze Core prosty rdzeń jest punktem wyjścia do rozwoju, nie ograniczeniem. System ma być wystarczający dla celu, a kolejne elementy powinny pojawiać się wtedy, gdy proces i dane uzasadniają ich koszt.