Что значит архитектура системы

Термин архитектура все чаще используется вне традиционного строительного контекста, и уже сейчас можно встретить много определений архитектуры (в контексте систем) и архитектуры систем, например:

«Архитектура системы: единая фундаментальная структура системы, описанная в терминах поведения, ограничений, процессов, интерфейсов и элементов системы».
[базовое определение, одобренное INCOSE Systems Architecture Working Group на конференции INCOSE 1996 в Бостоне (Массачусетс) 8 июля 1996 года]

«Архитектура системы описывает основные физические свойства, стиль, структуру, взаимодействия и предназначение системы».
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

«Архитектура — это набор концепций и правил, характеризующих структуру, семантическое поведение и взаимосвязь между компонентами системы; план конструирования чего-либо. В состав архитектуры входят элементы, образующие конструкцию, отношения между ними, ограничения на эти отношения, описание отдельных компонентов конструкции, а также описание конструкции в целом».
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2: Information Technology — Open Distributed Processing — Reference Model: Foundations, as the source]

«Архитектура — это структура компонентов программы (системы), взаимосвязей между ними и принципов их разработки и эволюции во времени».
[DoD 5000.59-P, «Modeling and Simulation Master Plan,» October 1995]

Архитектура — это «структура компонентов, взаимосвязей между ними и принципов их разработки и эволюции о времени».
[IEEE STD 610.12, extended slightly by the Integrated Architectures Panel (IAP) of the C4ISR Integration Task Force (ITF) in DoD Architecture Framework, Version 1.0]

Хотя эти определения оперируют различными терминами и охватывают различные наборы аспектов, они во многом пересекаются. Все определения сходятся в том, что архитектура описывает следующие компоненты:

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

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

Точки наблюдения

Точка наблюдения (в контексты системы) — это «форма абстракции, которая достигается с помощью определенного набора архитектурных концепций и правил структурирования для того, чтобы сфокусироваться на определенных аспектах системы» [ISO/IEC 10746-2: Information Technology — Open Distributed Processing — Reference Model: Foundations]. В следующей таблице приведены примеры точек наблюдения для различных аспектов системы. Эти точки наблюдения соответствуют стандарту ISO/IEC 10746-1: Information technology — Open Distributed Processing — Reference Model: Overview.

Точка наблюдения	Аспект	Сфера
Исполнитель	Исполнителя интересуют роли и сферы ответственности организации и сотрудников (и установленные для них правила).	Деятельность исполнителей, взаимодействие пользователей с системой. Человеческий фактор и производительность труда.
Информация	Виды информации, обрабатываемой системой, и ограничения на использование и интерпретацию этой информации.	Целостность информации, ограничения на объем. Доступность и актуальность информации.
Логика	Декомпозиция системы на набор подсистем, взаимодействующих через интерфейсы и обеспечивающих выполнение функций системы.	Поведение системы отвечает требованиям. Система поддерживает расширение, адаптацию, обслуживание. Активы допускают повторное использование.
Комплектация и физические характеристики	Инфраструктура, необходимая для обеспечения нормальной работоспособности системы.	Соответствие физических характеристик системы предъявляемым к ней функциональным и нефункциональным требованиям.
Процесс	Параллелизм, расширяемость, производительность, пропускная способность, надежность.	Соответствие системы требованиям к времени отклика, пропускной способности и отказоустойчивости.

Общие точки наблюдения.

Это одни из самых распространенных точек наблюдения для систем, ориентированных на программное обеспечение. Для многих систем также требуются дополнительные точки наблюдения, характерные для их предметных областей. Примерами таких предметных областей могут служить безопасность, защита и механическая организация системы. Каждая точка наблюдения охватывает определенный набор характеристик, которые должны быть учтены при разработке архитектуры и проектировании системы. Если архитектура системы во многом зависит от потребностей или точек зрения отдельных заинтересованных лиц или экспертов, целесообразно создать специальные точки наблюдения для них.

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

Уровни абстракции

Помимо точек наблюдения, в архитектуре системы необходимо создать уровни спецификаций. По мере разработки архитектура становится все менее общей и все более детализированной. В RUP различают четыре уровня архитектуры, перечисленные в следующей таблице.

Уровень модели	Выражает
Контекст	Система и ее субъекты.
Анализ	Описание начального набора компонентов системы на уровне концепции.
Эскиз	Реализация модели анализа на уровне аппаратного обеспечения, программного обеспечения и сотрудников.
Реализация	Реализация модели проекта в конкретных конфигурациях.

Архитектурные уровни RUP

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

Модели и диаграммы

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

Точка наблюдения, как следует из самого названия, это определенная «позиция», с которой наблюдатель видит определенные аспекты или компоненты системы. Для формирования точек наблюдения применяются фильтры, представляющие собой наборы концепций и правил. Как правило, для понимания системы недостаточно изучить модели существующих систем или систем, которые будут созданы в будущем.

Представления — это проекции моделей, в которые входят элементы, значимые для тех или иных точек наблюдения. Обычно для иллюстрации этих проекций применяются диаграммы.

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

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

Уровень модели	Точки наблюдения
Уровень модели	Исполнитель	Логика	Информация	Комплектация и физические характеристики	Процесс
Контекст	Организационное представление UML	Диаграмма контекста системы	Представление данных организации	Представление локальности организации	Представление бизнес-процессов
Анализ	Общее представление исполнителей	Представление подсистем	Представление данных системы	Представление локальности системы	Представление процессов системы
Эскиз	Представление исполнителей	Представления классов подсистем

Представления компонентов программного обеспечения

Схема данных системы Представление узлов дескрипторов Подробное представление процессов Реализация Инструкции и спецификации ролей исполнителей Конфигурации: диаграммы развертывания с компонентами программного и аппаратного обеспечения системы.

Многие представления из числа перечисленных в таблице построены на основе стандартных моделей UML. Например, на уровне анализа точки наблюдения логики система представлена в виде множества взаимодействующих подсистем, обеспечивающих выполнение требований пользователей. Подсистемы в данном случае используются в той же роли, что в стандарте UML. Эти подсистемы, в свою очередь, состоят из подсистем или (в конечном итоге) классов. Уровень проекта точки наблюдения логики соответствует подробному представлению модели классов. Модель процессов — это также стандартная модель классов UML, в которой основное внимание уделяется активным классам системы. В точки наблюдения определенных предметных областей также входят представления рабочих продуктов для одного или нескольких уровней. Набор рабочих продуктов проекта в данной среде должен представлять собой вариант разработки проекта.

Источник

Архитектура системы и Бизнес-архитектура

После достаточно продолжительного созерцания того, как различные специалисты объясняют (устанавливают) своё понимание архитектуры, я решил, что нужно им, всё-таки, помочь 🙂
Критиковать не стал, но предложить есть что.

Архитектура и строительные конструкции

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

Строительный проект состоит из двух основных частей: архитектурно-строительной и инженерной.

Архитектурно-строительная часть проекта включает:

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

Инженерная часть проекта состоит из детальных схем:

Системы водоснабжения и канализации – схема разводки водоснабжения, аксонометрическая схема водоснабжения, схема разводки канализации.
Отопления и вентиляции – схема разводки отопления, схема разводки вентиляции, обвязка котла (при его наличии).
Электроснабжения – разводка освещения, разводка силовых сетей, схема ВРУ, система по заземлению.

Архитектор занимается только архитектурными разделом, а конструкционным разделом и инженерной частью занимаются соответствующие инженеры.

… место для размышлений …

Архитектура системы

Теперь рассмотрим определение, которые ближе к IT. За основу возьму выдержки из статьи.

Архитектура – фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции. (Из: ISO/IEC/IEEE 42010:2011)

Архитектура – это проектные решения, которые тяжело изменить. (Мартин Фаулер)

Однако, существует тонкость с характеристикой «тяжело изменить».

Предположим, у вас есть проектное решение, которое описывает для ваших разработчиков, как они должны структурировать свой код на Java. Если у вас есть много кода, для изменения всего этого кода из одной структуры в другую потребует много работы. Другими словами, это тяжело. Следовательно, это выбранное решение является «архитектурой», в данном случае программной архитектурой. Но один разработчик может легко проигнорировать это решение и написать код, который делает всё по-другому. В конце концов, вносить «изменения» в программное обеспечение легко. Хотя всю реализованную архитектуру изменить тяжело, в ней часто достаточно легко можно изменять только отдельные части.

Нет никакой теоретической причины, что что-то трудно изменить в отношении программного обеспечения. Если вы выбираете какой-либо один аспект программного обеспечения, вы можете легко изменить его, но мы не знаем, как сделать всё легко изменяемым. Сделать что-то легким для изменения — делает общую систему немного сложнее, а сделать всё легким для изменения — делает всю систему очень сложной. (Ральф Джонсон)

Суть создания архитектуры — структурирование. Структурирование может означать превращение формы в функцию, извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель (Эберхард Рехтин).

Создание архитектуры – это деятельность по организации и поддержки системы из составляющих ее элементов. И все архитектурные принципы направлены на декомпозицию и организацию составных частей системы.

Проблема

Проблема у указанных выше определений, хотя они и полезные, всё же есть, они оторваны от идеи, заложенной в систему. Выделять архитектуру по критерию «тяжело изменить» довольно странно.

Также определение через составляющие в данном случае не передает необходимый смысл.

… место для размышлений …

Большая часть системных архитекторов вышло из программистов, они все технократы. Это всё придумали они. 🙂
При работе с архитектурой лучше сфокусироваться на назначение Системы.

Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.

Это проектное решение, которое колеса, двигатель, корпус и рулевое управление организует в автомобиль.

Другими словами, Архитектура – это проектное решение, которое дает эффект эмерджентности. Эмерджентность — появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
Важно не смешивать уровни абстракции. Также позже, может возникнуть вопрос, что такое хорошая архитектура? Архитектура должная обеспечивать реализацию трех основные атрибутов качества системы: надежность, эффективность, гибкость. Есть и другие, например, масштабируемость, тестируемость, ремонтопригодность и др., но они не всегда так важны.

Бизнес-архитектура

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

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

Субъекты – это организационно штатная структура.
Деятельность – это бизнес-процессы, функции и сервисы.
Объекты – это результат деятельности и материал для деятельности. При этом результатом и материалом может быть физическим или информационным.

Но всё же, этого будет недостаточно, чтобы это понять, нужно рассмотреть базовые концепции и принципы.

Концепция «Три вида деятельности»

Существуют три вида деятельности:

Управляющая — деятельность, которая управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление и Стратегический менеджмент.
Основная (Операционная) — деятельность, которая является основой бизнеса компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг, Продажи.
Поддерживающие — деятельность, которая обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, административно-хозяйственный отдел.

Поддерживающие деятельности часто отдают на outsource. Не всегда деятельности, указанные в примере выше «как основные» являются основными, потому что их тоже можно на outsource. Управляющая деятельность всегда есть, теоретически можно всё «зааутсорсить», кроме управления и сделать компанию виртуальной.

Концепция «Циклы Деминга»

Итак, мы как архитекторы разделили деятельность компании на три части. Теперь нужно понять, а как же это все вместе работает. Для этого нам потребуется еще одна старая, но по-прежнему актуальная концепция – цикл Деминга, он же PDCA:

Планирование

Действие

Проверка

Корректировка

Не нужно воспринимать её буквально, это больше метафора, и в разных компаниях она реализуется по-разному, но эти этапы всегда есть.

Посмотрим нашу конкретную проектную работу, производство продукта или оказание услуги:

Кто спланировал этот процесс?
Какие есть регламентные и нормативные документы?
Кто выполняет действия?
Как выполняется проверка?
Как выполняется корректировка?

Если с этапом «Действие» и «Проверка» всё, кажется, понятно, то «Планирование» и «Корректировку» нужно посмотреть поближе.

Концепция «Принятие решения»

Тут нам понадобится третья концепция – Принятие решения. Это универсальный подход для решения управленческих задач и проектного управления.

Уяснение задачи

Оценка ситуация

Разработка вариантов решения

Выбор решения

Важно понимать все шаги этой последовательности и что нужно для ее выполнения. Этот подход применяется при планировании и в зависимости от ситуации при корректировке.

Давайте сопоставим эту концепцию с нашими проектами:

Как выполняется уяснение задачи?
Как выполняется оценка ситуации?
…

А теперь поднимемся на уровень руководства.

Как руководство обеспечивается информацией в части корректировки и оценки ситуации, то есть, где отчеты по нашему проекту, чтобы они поняли хорошо всё или плохо?

Принцип «Целевое назначение должно определять архитектуру»

Тут важно напомнить определение архитектуры:

Целевым назначением обычно является основная деятельность. Управляющая деятельность направлена на основную деятельность. Поддерживающая деятельность обеспечивает ее.

Также не забываем указанные выше атрибуты качества: надежность, эффективность и гибкость. Основная деятельность вещь индивидуальная, но тут, я думаю, вы сможете разобраться с ней сами.

Принцип «Архитектура должна соответствовать руководству»

Без поддержки заинтересованных сторон архитектура не будет реализована. Нам придется изучить всех стейкхолдеров, их мотивы и цели.

Возможен внутренний конфликт.

… место для размышлений …

Определение Бизнес-архитектуры

Что касается специализированного определения, то с учетом того, что бизнес и IT идут сейчас плечом к плечу, по моему мнению, лучше Бизнес-архитектуру воспринимать как набор решений на верхнем уровне абстракций Архитектуры предприятия.

Из существующих определений мне нравится, которое дала группа Architecture Board Special Interest Group (BASIG) (Специальный совет по архитектуре OMG)

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

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

Архитектор

Если дать нормальное понятие архитектуры, то роль архитектора становится предельно понятной.

Задача сапожника изготавливать и ремонтировать обувь.

Задача архитектора создавать и управлять архитектурой. Он должен создать решение, которое соберет все другие решения в систему.

Какими компетенциями он должен обладать?

Архитектор должен знать архитектурные принципы и концепции на своем уровне бизнеса или системы, это его hardskills.

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

Есть еще одна характеристика, которая отличает архитектора от аналитика и программиста, он должен владеть оперативным искусством.

Источник