Обсуждение

Мой коллега трактует архитектуру как подмножество проектных решений, стоимость ошибок в которых нелинейно растёт со временем и для стадии начала эксплуатации сопоставима со стоимостью системы. Попросту говоря, если из-за ошибки в этом решении систему надо переделывать целиком — то это архитектурное решение. Дальше можно уже выделять пласты решений: опорная технология разбиение на подсистемы протоколы взаимодействия с окружением и т.д.

Я обычно даю много разных определений архитектуры. А на сайте SEI есть сборничек из где-то 250 разных определений. Определение вашего коллеги довольно распространённое и, конечно, тоже правильное. Но очень трудно объяснить, что все эти определения не позволяют "объективно" извне проекта определить, какие решения являются архитектурными, а какие уже нет. Ибо в момент принятия этих решений инженер не знает, ошибочно ли было принимаемое решение или нет -- и такое определение верно только задним числом и в сослагательном наклонении. Трудно, очень трудно с архитектурой. И с требованиями то же самое. В софте всё проще: накоплено огромное количество материала, а в случае железа и киберфизики многое приходится не столько брать из литературы, сколько самому додумывать (часто адаптируя какие-то идеи из программной инженерии, соединяя их с идеями из разных инженерных стандартов). Ну, и с примерами очень плохо: в открытом доступе крайне мало примеров хорошо документированных разработок железных (не радиоэлектронных, а именно железных -- все эти насосные агрегаты и прочие примеры типового оборудования, необязательно даже АЭС и подводные лодки) систем. Ничего, протопчем лыжню, по ней потом пойдут миллионы.

Тут ещё уместно подумать над стэком архитектур. Начиная от состава проектной документации по ГОСТ, который архитектура всех проектов в стране, и далее вверх, до архитектуры компоновочной схемы оборудования, которая может быть реюзнута во всех изделиях серии. И дальше вопрос отношений между ними, на который так и нет ответа. Это иерархия специализаций, или сеть неведомых отношений прототип-тип, или образец-результат.

но ведь из одних решений вытекают другие (или иначе: ограничения уже принятые решения накладывают на все последующие варианты выборов), это значит что неудача может быть обусловлена невозможностью сменить неправильный выбор из-за наложенного ранее ограничения, это значит что архитектурными являются решения "за которыми" тянется самый длинный хвост ограничений на выборы? такой граф выборов есть для любой системы, а значит можно найти и его вершины. их и объявить архитектурой.

Граф этот есть только в конце проекта. А где-нибудь поближе к началу проекта от этого графа есть махонький кусочек. Ибо architecturing -- это растянутый во времени процесс, и тяжело размышлять в первый месяц проекта о тех ошибках, которые будут осознаны только к пятому месяцу. Так что определение хорошо работает в пятый месяц, но мало что даёт для первого месяца.

посоветуйте, пожалуйста, из тех книг на полтыщи страниц, какую-нибудь толковую на русском языке

Увы, я на русском языке эти книги даже не отслеживаю -- они ведь все отстают лет на пять сразу, а хороших оригинальных работ на русском обычно нет, всё только переводное. Всё-таки традиция системной инженерии, включая архитектурное проектирование, пока не слишком развивается на русском. Хотя есть одна книжка, которая зубодробительна, не попсова ни разу и совсем не общий обзор архитектурного проектирования, но на русском языке и явно на архитектурную тему: Марк Левин, "Технология поддержки решений для модульных систем", 341с., 2013 (http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf). Эта книга доступна с его персональной страницы (http://www.mslevin.iitp.ru/) и страницы публикаций ИППИ РАН. Текст соответствует (частично) его факультетскому курсу «Проектирование систем» на ФРТК МФТИ (2004-2008). Книга на английском (существенно другая версия) находится на этапе представления в межд. издательстве -- так что и тут без английского не обойдётся, но это тот редкий случай, когда оригинал русскоязычный.

Стек чего-то (протоколов, например) -- это обычное слово для модульного описания: именно что стопка слоёв. Если дерево/иерархия, то там о стеке не говорят обычно. Стек появился бы в том случае, когда все эти прототипы-типы или образцы-результаты не имели бы права использовать элементы через уровень (ибо "стеки" это всегда про видимость интерфейсов). А тут действительно какие-то странные типы отношений, в том числе и отношения порождения (в смысле generative grammar): какая-то архитектура как набор синтаксических ограничений порождает все возможные конструкции в рамках этих ограничений. В программировании это обычно описывается не как стеки, а как цепочки (chains).

Стэк или цепочка, но в этом смысле они никогда не являются выражением модульности. Это всегда описание на разных уровнях, несравнимых друг с другом. Тут важно именно то, что один слой (или звено) можно пропустить или проигнорировать, но от этого не будет потеряна работоспособность системы, целиком и полностью определяемая самым верхним уровнем (последним звеном). Слово "стэк" обычно используется там, где среднем структура строится последовательно снизу вверх, а в цепочках программисты привыкли к тому, что вставка в середину - стандартная операция :-)

В каждой предметной области такой граф есть до начала работ (хотя бы в сознании эксперта). Иначе это получается не инженерия, а чистая фундаментальная наука (и даже там для построения эксперимента такой граф есть). Общий граф для разных областей скорее всего не существует, но ситуации выражаемые конфигурацией этого "графа ограничений" естественно могут повторятся.

Конечно, значительная часть архитектурных решений повторноиспользуема. И профессионал (по определению Нильса Бора) это тот, кто не допускает типичных ошибок в своей предметной области. Вопрос "системных архетипов" и прочих вариантов общих паттернов организации систем в системной инженерии время от времени тоже рассматривается, хотя это чаще в приложениях к организационным системам, а не к железным системам -- там разнообразие этих паттернов зашкаливает, поэтому им не уделяется слишком большого внимания. Открытые архитектуры тоже про это: публикация архитектуры позволяет разным мелким мира сего встраиваться со своими архитектурными решениями. Но системная инженерия особое внимание уделяет first-in-a-kind системам, для которых главные архитектурные решения ещё неизвестны, и поэтому самые важные решения нужно делать самостоятельно. Ну, и комбинаторика взаимовлияния разных уже известных решений такова, что известность графа не означает, что безошибочный путь по нему легко найти. Про науку и построение эксперимента -- боюсь, это не про сами эксперименты, а про методологию экспериментов. Конечно, все разговоры про архитектуру как таковую, без погружения в предметную область -- это методология системной инженерии, а не сама системная инженерия. Я об этом и пишу: методологически обычно всё понятно и абстрактно, а когда дело доходит до использования методологии -- вот тут будет затык. Ибо методологическая карта обычно требует огромной работы по соотнесению с территорией, и все обычно требуют, чтобы рассказ вёлся не в терминах карты (озеро, дом, дерево), а в терминах территории (вон та большая лужа, хижина на опушке, пальма в горшке).

спасибо!