Архитектура системы и Бизнес-архитектура
После достаточно продолжительного созерцания того, как различные специалисты объясняют (устанавливают) своё понимание архитектуры, я решил, что нужно им, всё-таки, помочь :)
Критиковать не стал, но предложить есть что.
Архитектура и строительные конструкции
Рассмотрим исходное понятия архитектуры и архитектора из области строительства:
Архитектура – это искусство проектирования и строительства зданий, сооружений и их комплексов, то есть искусство создания материально-организованной среды.
Архитектор – специалист, который на профессиональной основе осуществляет архитектурное проектирование, включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.
Строительный проект состоит из двух основных частей: архитектурно-строительной и инженерной.
Архитектурно-строительная часть проекта включает:
- Архитектурный раздел состоит из архитектурно-строительных чертежей, в которых указаны точные геометрические параметры здания, его конструкций и их элементов: планы этажей, полы, план кровли, фасады, разрезы, визуализация.
- Конструктивный раздел содержит общие данные, конструктивные решения фундаментов, перекрытий, крыши, чертежи отдельных узлов и деталей, спецификации изделий и материалов: фундаменты, перекрытия, перемычки, кровля, конструктивные узлы и детали.
Инженерная часть проекта состоит из детальных схем:
- Системы водоснабжения и канализации – схема разводки водоснабжения, аксонометрическая схема водоснабжения, схема разводки канализации.
- Отопления и вентиляции – схема разводки отопления, схема разводки вентиляции, обвязка котла (при его наличии).
- Электроснабжения – разводка освещения, разводка силовых сетей, схема ВРУ, система по заземлению.
Архитектор занимается только архитектурными разделом, а конструкционным разделом и инженерной частью занимаются соответствующие инженеры.
… место для размышлений …
Для 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.
Есть еще одна характеристика, которая отличает архитектора от аналитика и программиста, он должен владеть оперативным искусством.
… место для размышлений …
Ссылки
- http://www.ovikv.ru/строительный_проект.htm
- pubs.opengroup.org/architecture/togaf9-doc/arch/toc.html
- pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html
- docs.microsoft.com/ru-ru/dotnet/architecture/modern-web-apps-azure/architectural-principles
- www.omg.org/bawg/business_architecture_overview.htm