Historia Analizatora Różnicowego
Pierwsza reguła inżynierii systemów Hamminga: Jeśli zoptymalizujesz komponenty, prawdopodobnie zniszczysz wydajność systemu.
Ilustruje to historią ze swojej pracy. Operował analizatorem różnicowym — analogowym komputerem, który rozwiązywał równania różniczkowe poprzez integrację mechaniczną. Zapotrzebowanie rosło, dlatego zamówiono drugą jednostkę, którą należało połączyć z pierwszą, aby obie mogły działać niezależnie lub razem.
Konstruktorzy, dumni ze swojej pracy, ulepszyli wzmacniacze w nowej jednostce. Hamming nalegał: każde ulepszenie nie może ingerować w ogólne działanie systemu. W dniu przejęcia przeprowadził klasyczny test: rozwiąż y'' + y = 0, wykreśl y vs y', oczekuj doskonałego koła. Natychmiast się nie powiodło.
Przyczyna: ulepszone wzmacniacze pobierały więcej prądu przez obwód uziemienia. Niewystarczające uziemienie, które działało dobrze z oryginalnymi wzmacniaczami, teraz pozwalało prądom upływu się łączyć między podsystemami. Ulepszenie jednego komponentu (wzmacniaczy) pogorszyło interfejs (uziemienie), a system się zawalił.
Naprawa była trywialna — grubsza miedź w uziemieniu — ale zasada była jasna: ulepszenie komponentu zmienia jego zachowanie interfejsu. Reszta systemu została zaprojektowana wokół starego interfejsu. Ulepsz komponent, złam interfejs, podegradujesz system.
Rozpoznawanie Optymalizacji Komponentów
Hamming mówi, że reguła 'wydaje się tak rozsądna — jeśli ulepszysz izolowany komponent, to całość będzie lepsza' — a przecież jest błędna. Niepowodzenie jest pośrednicze przez interfejs: ulepszenie komponentu zmienia sygnał, który interfejs widzi.
Interfejsy Zamiast Komponentów
Praktyczne wnioski Hamminga: inżynierowie systemów muszą projektować i weryfikować interfejsy w pierwszej kolejności, komponenty w drugiej. Doskonały komponent z zepsutym interfejsem jest bezużyteczny. Przeciętny komponent z dobrze określonym interfejsem można ulepszyć później.
Reguła 2: warunki brzegowe (ograniczenia) systemu są często ważniejsze niż optymalne wartości wewnątrz tych granic. System zaprojektowany do maksymalizacji wydajności w oczekiwanym punkcie operacyjnym jest często kruchy: małe odchylenia poza oczekiwany zakres powodują awarie. System zaprojektowany do bezpiecznego działania w szerokim zakresie — z dobrze określonymi ograniczeniami — jest niezawodny.
Przykład: system komunikacyjny zaprojektowany dokładnie dla 100 Mbps ruchu przy 25°C będzie się zawiesać, jeśli ruch wzrośnie do 110 Mbps lub temperatura wzrośnie do 40°C. System zaprojektowany z ograniczeniem 'nie może przekroczyć 90% wykorzystania w żadnej temperaturze poniżej 60°C' jest bardziej użyteczny, nawet jeśli jego szczytowa wydajność jest nieco niższa.
Zadanie inżyniera systemów: nie optymalizować A lub B indywidualnie, ale optymalizować A+B+C... jako całość, z zachowaniem ograniczeń.
System Edukacyjny: Nieudana Inżynieria Systemów
Hamming stosuje swoją własną zasadę do edukacji. Przez dziesięciolecia uniwersytety optymalizowały indywidualne kursy matematyki: Rachunek różniczkowy został usunięty do jego istoty, Algebra liniowa została oczyszczona i zaostrzana. Każdy kurs, oceniany indywidualnie, wygląda lepiej.
Ale widziane jako system, pojawiły się duże luki:
- Indukcja matematyczna: ledwie wspominana po szkole średniej.
- Liczby zespolone: wprowadzone krótko w algebrze, następnie unikane aż do późna Algebry liniowej, gdy pojawiają się złożone wartości własne. Uczniowie stają przed dwoma nowymi, trudnymi ideami jednocześnie bez wcześniejszego przygotowania.
- Współczynniki nieoznaczone: krótko wspominane.
- Dowody niemożliwości: prawie całkowicie nieobecne.
- Matematyka dyskretna: w dużej mierze ignorowana.
Optymalizacja każdego komponentu (każdego kursu) stworzyła luki interfejsów: brakujące mosty pojęciowe między kursami. Wyjście systemu — wykształceni inżynierowie i naukowcy — ucierpiał, mimo że metryki wydajności każdego kursu się poprawiły.
Opieranie się Naturalnemu Pragnieniu Naprawienia Zepsutej Części
Obserwacja Hamminga: łatwo powiedzieć właściwe słowa o inżynierii systemów. Bardzo niewielu ludzi potrafi to faktycznie zrobić, gdy nadejdzie moment.
Naturalny odpowiedź, gdy system się zawali: zidentyfikować najbardziej oczywicie zepsuty komponent i go naprawić. To myślenie komponentem. System się zawalił z powodu, który wiąże się z interakcją komponentów, interfejsów i ograniczeń — ale najbardziej widoczna awaria zwykle występuje u jednego komponentu.
Dyscyplina inżyniera systemów: zanim naprawisz widoczną awarię, zapytaj: dlaczego system wyprodukowała awarię w tym komponencie? Czy komponent faktycznie niedostatecznie działa, czy jest proszbą o działanie poza jego obwiednią projektową przez resztę systemu? Naprawianie objawu komponentu pozostawia awarię systemu nienaruszoną.
Wąskie gardło komunikacyjne w dużych organizacjach podąża tym wzorem: dział komunikuje się słabo (widoczna awaria). Naprawa komponentu: wynajmij lepszych komunikatorów. Naprawa systemów: przeprojektuj architekturę przepływu informacji, aby wymogła się mniej komunikacji w celu osiągnięcia tej samej koordynacji.
Diagnoza Systemów
Rozróżnienie: naprawa komponentu leczy objaw. Naprawa systemów leczy przyczynę. Przyczyna zwykle wiąże się ze strukturą systemu — jakie komponenty istnieją, jakie interfejsy je łączą, jakie ograniczenia wiążą ich działanie.