Системное мышление

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

Деньги обычно приходят от удачного и массового использования верхнего, прикладного уровня. Но вот «перетряхивание» всего технологического/платформенного стека, перестройка всех рынков идут тогда, когда меняется принцип реализации самого нижнего уровня модулей, меняется платформа нижнего уровня. Например, когда в компьютерах поменялись механические или пневматические элементы на лампы, компьютеры стали масштабируемы и они начали напоминать уже функционально современные компьютеры, а не калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую технику позволила наладить массовый выпуск компьютеров и это разительно изменило компьютерную технику. Замена дискретной электроники на большие полупроводниковые интегральные схемы опять перевернуло весь компьютерный рынок со всеми надстройками программного обеспечения. Замена CPU на GPU перевернула рынок искусственного интеллекта. Замена людей-исполнителей на роботов-исполнителей переворачивает все промышленные предприятия. Эта особенность делает технологические/платформенные/модульные стеки удобными для обсуждения стратегии компании – обсуждается, что из модулей будет компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих модулей она будет устанавливать сама, а какие брать уже готовыми129.

Важность функциональных рассмотрений целевой системы

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

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

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

Вот пример, иллюстрирующий происходящее у программистов на примере более понятной работе с «железной» системой – но того же класса, что и программы: кажущейся суперуниверсальной по форме, но весьма конкретной и уникальной по содержанию.