Концепция системы и архитектура
Очень часто те люди, которые описывают систему, хотят указать не только внешние свойства системы, описать не только границы системы и её поведение как чёрного ящика, но заодно и указать какие-то детали внутреннего устройства системы: определить (define) части системы (подсистемы), указать на процесс взаимодействия подсистем. В этом случае о системе говорят как о «прозрачном ящике», в нём можно считать известными какие-то подсистемы, свойства и поведение этих подсистем. Это можно считать указаниями по концепции системы: какое поведение ожидается от внутренних частей системы (время их работы, функции подсистем), какими частями конструкции системы (конструкция подсистем) это поведение может быть реализовано, при этом важно ещё учитывать и пространственные аспекты, и аспекты полной стоимости. Концепция системы описывает «прозрачный ящик» --- это минимально четыре взаимоувязанных обязательных вида системных описаний, но чаще всего этих видов описаний по разным предметам интереса больше.
В любом случае, начнём хотя бы с двух: функциональное и конструктивное описания в их взаимоувязке. Скажем, вы готовитесь изготовить дверь, и вдруг вам внешние проектные роли говорят: «замок в двери должен быть из титана».
Слово «должен» указывает на требования, а не гипотезу, и это настораживает. А вдруг вы найдёте материал лучше? Для чего это вдруг потребовалось указывать, чего в поведении двери боится тот, кто описывает эту дверь? Какой испорченный телефон тут сработал, кто задал сценарий использования, что появилось это требование? Откуда вообще в двери замок, ибо вы и не подозревали, что дверь должна была бы запираться и отпираться: этого не было в концепции использования. Мы понимаем, что это описано ограничение свободы разработчика: один разработчик::роль указал другому разработчику::роль, что там должно бы быть внутри системы, чтобы при разработке концепции системы это ограничение было учтено. Вопрос: откуда разработчик::роль взялся во внешних ролях проекта. Иногда разработчиков целевой системы на зарплате у организации-заказчика называют «инжиниринг заказчика», и им платят зарплату как раз для того, чтобы они создавали такие ограничения свободы внешних разработчиков --- чтобы, например, у внешних разработчиков не возникало соблазнов излишне удешевить-упростить или задрать цену-усложнить конструкцию системы.
Обычно организация проекта (например, коллектив из нескольких команд) согласовывает с внешним заказчиком системы функции/поведение, которые должна бы выполнять целевая система как чёрный ящик, свойства этого чёрного ящика, т.е. разработчики согласовывают концепцию использования (чаще всего даже не всю, а какие-то отдельные сценарии использования по отдельным «фичам», которые будут реализовываться какой-то отдельной командой), а архитектор системы согласовывает архитектурные характеристики и их приемлемые значения для всех команд разработчиков. Не факт, что эти гипотезы по концепции системы и приемлемым архитектурным характеристикам формулирует заказчик! Это совместная с заказчиком работа. Как устроена система внутри, то есть какие функции выполняют подсистемы и какими физическими объектами реализована конструкция системы --- это коллектив проекта определяет самостоятельно, заказчика больше интересует обычно надсистема, она для него «прозрачный ящик», а целевая система --- «чёрный ящик». Более того, это часто делается не за один приём, а долго --- и продолжается даже после того, как первая версия (MVP, minimal viable product) уже изготовлена и начала использоваться. Часто самые интересные идеи и у агентов-заказчиков в самых разных их ролях, и у агентов-исполнителей этого заказа будут появляться уже после появления MVP, в ходе последующего развития системы.
Решения «прозрачного ящика» по тому, как система делится на конструктивные части (модули) и как эти модули будут взаимодействовать, чтобы значения архитектурных характеристик удерживались в приемлемых пределах (например, система в ходе улучшений продолжала оставаться легко изменяемой) называют архитектурой. Обратите внимание: архитектура --- это решения по устройству системы в части конструкции (модули/конструктивы и способ их связи), равно как и концепция системы --- это тоже решения по устройству системы, но включают и функциональные объекты, и конструктивные как аффордансы для этих функциональных объектов, а также пространственные (компоновка/размещение/location/allocation) и выходят на полную стоимость владения, и ещё могут включать какие-то важные другие аспекты (скажем, отдельно выделенные этические и юридические рассмотрения, или эстетические и художественные рассмотрения, в каждом проекте могут появляться какие-то особенности).
Концепция системы --- это не архитектура (хотя ещё десяток лет назад считалось, что концепцию системы разрабатывают архитекторы), а архитектура --- не концепция системы. Функциональность системы в надсистеме определяется решениями в концепции системы, а вот важные характеристики вроде «способность системы к развитию, лёгкость внесения изменений в конструкцию» определяются архитектурными решениями.
Архитектурные решения/architecture decisions оформляются самыми разными способами, например, описаниями с предписанной структурой на нескольких страницах в виде записей архитектурных решений/architecture decision records. Архитектурные решения представлены списком таких записей, или какой-то таблицей с материалом таких записей. Архитектура --- это абсолютно не «диаграмма». Диаграммы в проекте чаще всего не архитектурны, а если и обнаруживаются где-то в архитектурном решении, то оказываются использованы в чисто иллюстративных целях, а не выражают архитектурные решения. Не надо путать системную архитектуру со строительной архитектурой, где прежде всего речь идёт о внешнем виде здания, а главное для архитектора умение --- это умение рисовать.
Подробней об архитектурных решениях и их записи говорится в «Системной инженерии», но главное пока запомнить: вы ничего не можете сказать про «прозрачный ящик» (ни обсуждать концепцию системы, ни обсуждать архитектуру системы), пока вы не выясните, что там с «чёрным ящиком», то есть поведением системы в её окружении. Если вы не знаете, что делает сепулька, то вы ничего не сможете сказать о том, как она может быть устроена!
Это главное, что нужно запомнить в системном мышлении: первое же рассмотрение системы --- это концепция использования, а не концепция системы, не архитектура системы. Сначала смотрим от границы системы в окружающий мир, в среду, причём в момент эксплуатации (если вы разрабатываете систему, то это надо вообразить, ибо эксплуатация будет в будущем), и рассматриваем поведение/функцию системы. А потом только начинаем смотреть на прозрачный ящик. Если мы начинаем рассматривать шестерёнки в механических часах, а потом вдруг смотрим в окружение часов, то можем увидеть, что часы эти расположены в ракете, и должны бы отсчитывать миллисекунды, штатно работая с перегрузками в 30G, ибо там всё вибрирует рядом с двигателем, около которого установлены эти часы. Можете забыть с этого момента про шестерёнки, это было зря потраченное время! Сначала смотрите вокруг, от границы системы наружу в момент эксплуатации, а потом только внутрь системы в момент эксплуатации, и потом только внутрь системы в момент её создания!
В любом случае, все эти описания системы (концепция использования, концепция системы и архитектурные решения) --- гипотезы, готовьтесь их менять, торгуйтесь, предлагайте свои варианты, внимательно выслушивайте варианты, которые предлагают внешние проектные роли, обязательно занимайтесь обоснованиями. «Я так хочу» --- это не аргумент, ибо сейчас хочу так, завтра хочу по-другому, или «вы не так меня поняли, я хотел другого», или вас в этой роли подменит какой-то другой агент, и он будет хотеть по-другому --- это же «хочу» должно быть информированным мнением роли, а не простым желанием агента.