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

Почему же используется два слова? Потому что по факту проверяется работоспособность двух систем, проводятся два набора испытаний: проверочные (целевой системы, соответствие её требованиям) и приёмочные (использующей системы, соответствие её потребностям).

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

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

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

Так, «цвет» шкафа тоже есть, но есть и описание цвета – слово «чёрный», код цвета по одной из цветовых моделей 141 141 https://colorscheme.ru/ или даже попытка воспроизвести этот цвет ■ (на каком-то носителе, вот прямо как тут). Но если есть шкаф, то и цвет у него есть. И архитектура у шкафа есть. Но может не быть описание цвета (нигде не будет написано, какой у шкафа цвет), как может не быть описания архитектуры.

Об описании цвета или архитектуры мы говорим, или о самом цвете или архитектуре – это понимаем из контекста, или проговариваем явно. Если мы говорим «цвет нужно сделать почернее», то это про цвет, а если «цвет в кодировке RGB», то про описание цвета. С архитектурой всё то же самое.

ISO 42010 даёт следующее определение архитектуры: «Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития» 142 142 Architecture (of a system) – fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. . Обратите внимание, что в этом определении нет никакого упоминания структуры системы. Ибо для такой системы как интернет нельзя указать на структуру системы: в интернете никто не знает, что входит в структуру интернета в каждый конкретный момент, какие есть связи между элементами этой системы, непрерывно появляются и исчезают новые узлы интернета и между ними непрерывно появляются и исчезают новые каналы связи. Но определение от этого не стало понятней.

Вот другое определение архитектуры, от части авторов того же ISO 42010, но данное ими в книге про документирование системных архитектур 143 143 Paul Clements at al., Documenting Software Architectures: Views and Beyond : «Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений» 144 144 The architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. . Там наоборот, дан акцент на структуры.

Но самых разных определений много больше, и в интернете есть место, где собрано более 150 таких определений 145 145 http://www.sei.cmu.edu/architecture/start/glossary/community.cfm . Самые разные стейкхолдеры определяют архитектуру по-разному, с акцентом на те или иные её свойства, те или иные классы целевых систем.

Мы будем придерживаться неформального простого и понятного определения архитектуры, которое дал Ralf Johnson: « Архитектура – это обо всём важном. Что бы это ни было.» 146 146 Ralf Johnson: «Architecture is about the important stuff. Whatever that is», https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf . .

Эти слова обычно указывают на важные решения, которые могут быть для «железных» систем инженерные, для предприятия организационные, менеджерские или предпринимательские, в случае танцев – постановочные решения, и т. д. Важные решения определяются как такие, в случае принятия альтернативных решений по ним придётся перепринять большинство других решений, то есть перепроектировать и затем переделать всю систему. Так, если при проектировании самолёта принято решение сделать его с реактивным двигателем, а не обычным поршневым, то это означает переделку практически всей конструкции: от устройства топливной системы до формы крыльев и фюзеляжа. Если в здании принято решение печатать его на бетонном 3D-принтере, а не выкладывать его из бетонных блоков или даже из кирпича, то смело можно переделывать всю проектную документацию – или переделывать весь дом, если он уже построен.

Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь проект/design тем самым делится на две части: архитектура и неархитектурная часть проекта(non-architectural part of design).

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