[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Центральной дисциплиной в системной инженерии, да и, собственно, в инженерии предприятия, является архитектура. Архитектурная деятельность. Architecting. И центральным описанием, с которым работают разработчики, является архитектурное описание. И тут мне, по идее, надо дать определение архитектуры, что это такое. Я могу сказать какие-то слова формальные, например, привести определение из ISO 42010, что архитектура (системы) — это основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития. Но вам это ничего не скажет. Я вам могу долго рассказывать, например, как люди считают, что архитектура — это определение основных структур системы: функциональной структуры, конструктивной структуры, структуры размещений. Но это тоже ничего не скажет, тем более, что слово «структуры» недаром было убрано из ISO 42010. Потому что мы говорили, что определение системы, а архитектура — это часть определения системы, оно есть всегда. Это означает, что если у нас есть система такая, например, как Интернет, то у Интернета есть структура. Но мы же не знаем структуру Интернета. В какой-то момент в Интернет пришло множество новых узлов, и ушло, например, перерезали атлантический какой-нибудь кабель, трансатлантический, ушло много новых узлов. Появились новые пользователи, ушла старая аппаратура. Вы же помните, что Интернет в какой-то момент включили, и с тех пор человечество его не выключало, это одна из немногих систем, которая работает, работает, самая надёжная, бесперебойная, не выключалась ни разу с момента её создания десятки лет назад. Ни на какие профилактические ремонты. Беда — структуры нет. Потому что всё это время структура менялась. И мы поэтому не можем слово «структура», хотя мы все интересуемся структурой для создания наших систем, мы не можем даже слово «структура» оставить в понятии «архитектура». Более того, у нас дикие споры до сих пор идут о том, что такое архитектура. Вы видите ссылку, в которой есть набор из более чем 150 определений архитектуры. Эти споры, что такое настоящая архитектура, они до сих пор не погасли. Итак, важно какие типы структур системы документируются, какие принципы проектирования, конструирования и развития документируются, но, вот что именно делать, мы не можем сказать, на уровне определения мы это не можем вынести. Поэтому победило в конечном итоге определение Ральфа Джонсона. Оно неформальное, оно родилось в одной огромной интернет-дискуссии. Архитектура — это обо всём важном. Что бы это ни было. Осталось только определить, что же у нас является важным. Что важно в инженерной системе? Мы считаем, что архитектура, которую многие представляют как какую-то картинку, на которой нарисована какая-то структурка, ещё другая картинка, на которой нарисована какая-то структурка, мы считаем, что эти картинки, они просто отражают последовательность принятых архитектором решений. Важных решений. Важным мы считаем то решение, которое, если мы его приняли, то после него все другие решения надо будет сделать какими-то одними, а если мы приняли его по-другому, то надо будет сделать какими-нибудь другими. Итак, что у нас важное, например, в самолёте? Мы принимаем решение, что у нас будет биплан. Всё. Если у нас два крыла, то мы делаем одну конструкцию самолёта. Если мы приняли решение об одном крыле, то нам практически весь самолёт надо перепроектировать. Но мы можем сказать, что там есть и другие важные решения. Например, если мы приняли решение, что в самолёте есть двигатель реактивный. Опять можно перепроектировать весь самолёт по сравнению с тем, если мы приняли решение, что двигатель внутреннего сгорания, и используется винт. И вот таких решений набирается некоторое количество, они могут быть отображены на диаграммах, высказаны словами, не отображены на диаграммах. Вот эти решения, они принимаются последовательно друг за дружкой, иногда независимо друг за дружкой, иногда не друг за дружкой. В разные моменты проекта, например, в самом конце проекта мы принимаем решение что-то поменять, и вынуждены буквально переделывать всю систему с нуля, потому что это решение оказывается архитектурным. Но вот эти решения мы и называем важными. Мы делаем компрессор. Винтовой компрессор против спирального, против турбокомпрессора. Абсолютно разные конструкции, на разных заводах, на разных станках, разные чертежи, разные принципы действия, разные физические модели для расчёта компрессора. Хорошо, мы сказали турбокомпрессоры. Следующее решение. Масляные против безмасляных. Мы смазываем или не смазываем ротор, когда он вращается. А ротор турбокомпрессора вращается очень быстро. Хорошо, мы говорим, безмасляный, нам не надо делать масляный насос и всё масляное хозяйство, мы хотим, чтобы было попроще. Нам тут же говорят: активная против пассивной подвески. Мы говорим: активная подвеска — это очень сложно, потому что вы должны сделать электромагниты, датчики, и вы должны на электромагнитах всё время отслеживать положение ротора и делать так, чтобы ротор парил в магнитном поле. Хорошо, мы не будем этого делать, мы будем говорить, что пассивная подвеска. Дальше спрашивают: газостатическая подвеска против газодинамической. В общем, вы меня поняли, что каждый раз, когда вы принимаете какое-то решение, если вы решили его повернуть назад и принять другое решение, вам придётся перепроектировать практически весь турбокомпрессор. Начиная с того, что он может быть и не турбокомпрессором. Это уже какое-то решение, если вы выбрали турбокомпрессор, могли выбрать какое-то другое. Итак, у вас есть важные решения, которые, если вы принимаете их в другую сторону, иногда говорят, вы проходите развилки, в системной инженерии это trade of studies. Прохождение развилок. Если вы вот в этой развилке приняли одну сторону, а не другую, то это означает, что все ваши решения дальше намного предопределены, и вряд ли речь идёт о винтике, если вы приняли решение, что винтик будет другой, то вы перепроектируете только винтик, но если вы приняли какое-то большое решение и дальше надо всё перепроектировать, вы точно имеете дело с архитектурой. И есть такие требования, которые говорят, что вы должны принять то или иное архитектурное решение. Эти требования, важнейшие требования, будут называться архитектурными требованиями. Например, если самолёт летит со скоростью, скажем, 900 км/ч, то это нормальный самолёт, нормальное требование. Архитектурное, правда, требование. Потому что если выяснится, что самолёт летит со скоростью, например, 3000 км/ч, то там уже число Маха поучаствовало, это означает, что самолёт стал сверхзвуковым, и это означает, что вы должны полностью поменять конструкцию, перепроектировать всё, следовательно, скорость самолёта является архитектурным требованием к самолёту. Архитектурные и неархитектурные решения абсолютно субъективны. Что для одного архитектора является важным, для другого архитектора, исходя из его опыта, из его понимания ситуации, будет казаться неважным. Бывают такие архитектурные review, как говорят, или просмотры. Архитектурные обсуждения, рассмотрения, когда другие разные эксперты показывают архитектору, что то или иное решение, которое он принял, является на самом деле важным. Архитектор представляет список этих своих решений, а ему помогают дополнить этот список теми решениями, которые он считает не важными, а само собой разумеющимися, и говорят, что он мог принять другое решение, тем самым хоть как-то уходя от вот этой субъективности. Кроме того, мы понимаем, что архитектурные и неархитектурные решения, они относительны. Вот вы видите диаграммку, где кто-то ответственный за, например, весь самолёт или за, например, всю собачью конуру. И есть кто-то, кто ответственный за двигатель самолёта или за одну досочку собачьей конуры. И те решения, которые абсолютно неважны для того, кто занимается самолётом в целом, например, решения по топливному насосу для двигателя, являются важными для того человека, который занимается этим двигателем. То есть фактически неразличимо с уровня системного инженера, кто занимается архитектурными решениями, неразличимо решение, принятое в самом низу, архитектурное по топливному насосу, и то это не самый низ, это архитектурное важное решение. А внизу это решение будет вполне архитектурным. То есть разные люди архитектурой будут называть абсолютно разные решения в рамках разделения труда. И критерий, где же остановиться. Остановиться системному инженеру принимать свои архитектурные решения и поручить всё дальше надо там, где он понимает, что он разбил систему на достаточное число частей, чтобы обеспечить целостность, чтобы люди могли дальше принимать свои архитектурные решения. Это вот задача системного инженера. Напомню я, что это только роль — системный инженер. Инженер-архитектор, более того, узкая, частная роль. Один человек может выполнять множество ролей, он может выполнять роли и всех архитекторов на всех уровнях системы и всех инженеров по требованиям, и, например, быть ещё не системным инженером, а, например, инженером-электриком и любым другим инженером. Но в данном случае мы понимаем, что речь идёт о ролевом разделении труда, и эти решения по архитектуре субъективны и относительны. Итак, мы понимаем архитектуру как функция и конструкция. Это означает, что архитектура — это функциональная структура и конструктивная структура соответствия функций и конструкции в их самых важных чертах. Или оно же как компоненты, плюс модули, плюс размещение, опять же, только важные, верхнеуровневые. Или оно же как принципиальная схема, то, как связаны компоненты, заказная спецификация. Те модули, которые у нас есть. Плюс компоновка, где это всё находится во Вселенной. Но только, опять же, важные, верхнеуровневые. Или оно же как логическая архитектура. Логическая, альфы, компоненты, функциональная структура. Плюс физическая архитектура: модули и размещение. Опять же, при учёте возражения, что нельзя говорить исключительно о частных, вот только о логической архитектуре и физической архитектуре, потому что архитектура — это все важные решения. Помните, все важные решения. Но исторически так уже говорят, что логическая архитектура, физическая архитектура — это разные понятия. Итак, логическая архитектура и физическая архитектура вместе — это архитектура, и мы помним, что это, опять же, только всё важное. Или оно же просто список, смотрите, даже без диаграмм, а просто список вот, может, в Excel-табличке какой-то важнейших принятых конструкторских или проектных решений по вашей целевой системе.
