Історія диференціального аналізатора
Перше правило системної інженерії Хеммінга: якщо ви оптимізуєте компоненти, ви ймовірно зруйнуєте продуктивність системи.
Він ілюструє це історією з його власної роботи. Він керував диференціальним аналізатором — аналоговим комп'ютером, який розв'язував диференціальні рівняння механічною інтеграцією. Попит зростав, тому був замовлений другий пристрій для з'єднання з першим, щоб обидва могли працювати окремо або разом.
Конструктори, горді своєю майстерністю, поліпшили підсилювачі в новому пристрої. Хеммінг наполегливо стверджував: будь-яке поліпшення не повинно перешкоджати загальній роботі системи. На день приймання він запустив класичний тест: розв'язати y'' + y = 0, побудувати графік y проти y', очікувати ідеальне коло. Це одразу не вдалося.
Причина: поліпшені підсилювачі споживали більше струму через коло заземлення. Недостатнє заземлення, яке працювало добре з оригінальними підсилювачами, тепер дозволяло струмам утечки з'єднуватися між підсистемами. Поліпшення одного компонента (підсилювачі) погіршило інтерфейс (заземлення), і система не працювала.
Рішення було тривіальним — важчі мідні дроти заземлення — але принцип був ясний: поліпшення компонента змінює його поведінку на інтерфейсі. Решта системи була розроблена навколо старого інтерфейсу. Поліпшіть компонент, розпочніть інтерфейс, погіршіть систему.
Розпізнавання оптимізації компонентів
Хеммінг каже, що це правило 'здається настільки розумним, якщо ви зробите окремий компонент кращим, то вся система буде краще' — і все ж це неправильно. Невдача опосередкована інтерфейсом: поліпшення компонента змінює сигнал, який бачить інтерфейс.
Інтерфейси перед компонентами
Практичний висновок Хеммінга: системні інженери повинні розробляти й перевіряти інтерфейси першими, компоненти другими. Ідеальний компонент із розбитим інтерфейсом непридатний. Посередній компонент з добре визначеним інтерфейсом може бути поліпшений пізніше.
Правило 2: граничні умови (обмеження) системи часто важливіші за оптимальні значення в цих межах. Система розроблена для максимізації продуктивності в очікуваній робочій точці часто крихка: невеликі відхилення від очікуваного діапазону викликають відмови. Система розроблена для безпечної роботи в широкому діапазоні — з добре визначеними обмеженнями — стійка.
Приклад: система комунікацій розроблена для рівно 100 Мбіт/с трафіку при 25°C не працюватиме, якщо трафік зростає до 110 Мбіт/с або температура підвищується до 40°C. Система розроблена з обмеженням 'не повинна перевищувати 90% використання при будь-якій температурі нижче 60°C' більш корисна, навіть якщо її пікова продуктивність трохи нижча.
Робота системного інженера: не оптимізація A або B окремо, а оптимізація A+B+C... як цілого, з урахуванням обмежень.
Освітня система: невдала системна інженерія
Хеммінг застосовує свій власний принцип до освіти. Протягом десятиліть університети оптимізували окремі курси математики: Обчислення були скорочені до суттєвого, Лінійна алгебра була очищена й урізана. Кожен курс, оцінений окремо, виглядає краще.
Але розглянутий як система, з'явилися великі прогалини:
- Математична індукція: ледве згадується після початкової школи.
- Комплексні числа: введені коротко в алгебру, потім уникаються до пізно в лінійній алгебрі, коли з'являються комплексні власні значення. Студенти стикаються з двома новими, складними ідеями одночасно без попередньої підготовки.
- Невизначені коефіцієнти: коротко згадуються.
- Докази неможливості: майже повністю відсутні.
- Дискретна математика: значною мірою ігнорується.
Оптимізація кожного компонента (кожного курсу) створила пропуски інтерфейсу: відсутність концептуальних мостів між курсами. Вихід системи — освічені інженери й вчені — страждав, навіть якщо показники результатів кожного курсу поліпшилися.
Опір природному бажанню виправити зламану частину
Спостереження Хеммінга: легко висловити правильні слова про системну інженерію. Дуже мало людей можуть насправді це робити, коли приходить момент.
Природна реакція при відмові системи: визначити найяскравіше зламаний компонент і виправити його. Це думання про компоненти. Система не працювала через причину, яка включає взаємодію компонентів, інтерфейсів і обмежень — але найвидиміша невдача зазвичай на одному компоненті.
Дисципліна системного інженера: перед виправленням видимої невдачи запитайте: чому система виробила цю невдачу в цьому компоненті? Чи компонент насправді недовиконує роль, чи його просять працювати за межами його конверту дизайну рештою системи? Виправлення симптому компонента залишає невдачу системи недоторканою.
Комунікаційне вузьке місце в великих організаціях слідує цій схемі: відділ спілкується погано (видима невдача). Виправлення компонента: найняти кращих комунікаторів. Системне виправлення: переконструювати архітектуру інформаційного потоку, щоб було потрібно менше комунікації для досягнення тієї ж координації.
Системна діагностика
Розрізняння: виправлення компонента лікує симптом. Системне виправлення лікує причину. Причина зазвичай включає структуру системи — які компоненти існують, які інтерфейси їх з'єднують, які обмеження обмежують їх роботу.