Анатолий Левенчук - Системное мышление

На диаграмме видно, что в разных стандартах связи определяются пять уровней (по отношению часть-целое) модулей, которые можно разделить реализующих передачу физического сигнала (physical), передачу данных (Data Link), использующую передачу физического сигнала, и так далее. Неважно, что делают эти уровни платформенного стека, но главное тут то, что никакой модуль вышестоящего уровня «не видит» модули более низкого уровня (не имеет к ним доступа, не может туда «воткнуться»), чем находящийся непосредственно под ним, и интерфейсы реализующих сервисы этих платформенных уровней стандартизованы – как стандартизован и сам набор этих уровней.

Есть два способа чтения таких модульных диаграмм: на некоторых диаграммах «платформа» именуется стандартом, а реализация этого стандарта находится как бы «между уровнями» (ровно этот способ показан на диаграмме, он самый распространённый), и показ собственно модулей (именование платформ), тогда API этих модулей либо считаются проименованные самим модулем (скажем, модуль TensorFlow имеет API TensorFlow, и поэтому его не нужно отдельно прописывать), или если платформенный уровень реализует стандарт, то он прописывается где-то в границах реализующего его модуля отдельной строчкой поближе к границе использующего модуля, или даже выносится и явно прописывается «между платформами», как это сделано в картинке стека безопасности приложений 127 127 https://f5.com/about-us/blog/articles/why-cves-should-be-given-priority-one-for-resolution-27910 – стандарты указаны сбоку картинки платформенного стека, а каждая плашка обозначает слой модулей:

Верхняя скобка для стандарта интерфейса в использующую систему от custom code ведёт как бы в никуда при таком способе показа, поэтому чаще используется способ предыдущей картинки, где платформа обозначается не по назначениям/именам её модулей/слоёв, а назначение указывается сбоку.

Часто оба этих способа перемешивают, получая гибридную диаграмму. Вот, например, модульная диаграмма компилятора искусственных нейронных сетей, где верхние строки – наименования программных модулей-пакетов реализации нейронных сетей (например, пакет MXNet), а нижние – интерфейсных стандартов для какой-то аппаратуры (например, стандарт OpenCL) 128 128 http://www.tvmlang.org/2017/10/06/nnvm-compiler-announcement.html :

Платформенность даёт возможность эффективного разделения труда: реализацией каждого уровня платформенного стека может заниматься отдельная команда, и команды могут соревноваться за эффективность реализации. Инженеры, использующие какие-то платформы для создания своих целевых систем, могут не задумываться, как именно и из каких систем были сделаны эти платформы. Они могут просто использовать прикладной интерфейс этих платформ. А если этот прикладной интерфейс стандартизован, то они могут ещё и выбрать подходящий им по цене и характеристикам вариант реализации. И это происходит на много уровней вверх и много уровней вниз по технологическому стеку.

Деньги обычно приходят от удачного и массового использования верхнего, прикладного уровня. Но вот «перетряхивание» всего технологического/платформенного стека, перестройка всех рынков идут тогда, когда меняется принцип реализации самого нижнего уровня модулей, меняется платформа нижнего уровня. Например, когда в компьютерах поменялись механические или пневматические элементы на лампы, компьютеры стали масштабируемы и они начали напоминать уже функционально современные компьютеры, а не калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую технику позволила наладить массовый выпуск компьютеров и это разительно изменило компьютерную технику. Замена дискретной электроники на большие полупроводниковые интегральные схемы опять перевернуло весь компьютерный рынок со всеми надстройками программного обеспечения. Замена CPU на GPU перевернула рынок искусственного интеллекта. Замена людей-исполнителей на роботов-исполнителей переворачивает все промышленные предприятия. Эта особенность делает технологические/платформенные/модульные стеки удобными для обсуждения стратегии компании – обсуждается, что из модулей будет компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих модулей она будет устанавливать сама, а какие брать уже готовыми 129 129 Болваны для искусственного интеллекта http://ailev.livejournal.com/1356016.html , NVIDIA как поставщик инфраструктуры для интеллект-стека, https://ailev.livejournal.com/1380163.html , NVIDIA как поставщик инфраструктуры для роботакси-стека https://ailev.livejournal.com/1384766.html .

Частой ошибкой в разработке систем является игнорирование явного моделирования функциональной структуры системы, её принципиальных схем. В электронике и электрике, а также работе с непрерывными производствами (химические и энергетические предприятия) принято рисовать принципиальные схемы, на которых явно обозначаются компоненты, т.е. функциональные элементы системы. Но эта практика существует отнюдь не для всех видов систем. Так, в программной инженерии функциональных диаграмм в большинстве команд рисовать не принято. То есть программисты думают о функциональности своих программ, но принципиальных схем их работы программисты почему-то не делают, они держат обрывки этих принципиальных схем исключительно в уме – и поэтому в этих схемах нельзя найти пробелы, ошибки, поговорить о функционировании их систем с коллегами. В передовых кругах разработчиков софта это не так, и функциональные диаграммы документируются, но пока это ещё не общепринятая практика.

Неработа с функциональностью – типичная ошибка объединившихся в проекте инженеров и менеджеров-маркетологов (проект кто-то принёс! значит маркетологи были!). «Техпредприниматели» или корпоративные менеджеры беседуют с внешними стейкхолдерами и выясняют обычно их потребности, требованиями не занимается вообще никто, а инженер потом создаёт модульную конструкцию «на вырост», соединяя через типовые интерфейсы типовые конструктивные элементы в надежде, что через восемь итераций всё как-то само-собой с функциональностью утрясётся, и проект получится.

Ошибку такого рода в архитектурных диаграммах легко найти: в них при такой ошибке отсутствия функциональности нет отражения предметной области, для которой целевая система осуществляет сервис. Например, в архитектуре информационной системы магазина появляется просто «база данных», а не «цены товарных позиций, правила предоставления скидок, история покупок». Понятно, что всё это должно где-то храниться, но не факт, что в нарисованной программистом на первой же его диаграмме «базе данных» (часть, например, может браться на API какого-то сервиса, а правила представления скидок могут храниться в настроечном файле или вообще оказаться искусственной нейронной сетью), и не факт, что даже «база данных» будет одна. Объяснить программисту про необходимость рисовать функциональные диаграммы в составе архитектуры трудно, ибо он мыслит модулями, которые по его мнению абсолютно универсальны и поддержат «любую функцию». Любую-любую? Нет, конечно. Но разочарование будет не в начале проекта, а поближе к концу – когда окажется, что универсальных прикладных софтверных систем не бывает, так же, как и любых универсальных систем других.