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

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


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

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

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

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

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

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

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

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

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

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


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

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

Такие и подобные определения обычно использует в крупных архитектурных фреймворках, наподобие TOGAF и SAFe. Эти фреймворки достаточны тяжелы и состоят из небольшого набора практик, которые систематизированы и разбавлены множеством различных методик и приемов. И это всё-всё преподносится как «лучшие практики», хотя никто не тестировал и не применяет их в таком виде целиком.
Архитектура – это проектные решения, которые тяжело изменить. (Мартин Фаулер)

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

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

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

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

Проблема


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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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.

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

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

Ссылки


  1. http://www.ovikv.ru/строительный_проект.htm
  2. pubs.opengroup.org/architecture/togaf9-doc/arch/toc.html
  3. pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html
  4. docs.microsoft.com/ru-ru/dotnet/architecture/modern-web-apps-azure/architectural-principles
  5. www.omg.org/bawg/business_architecture_overview.htm