Архитектура и архитекторы

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

Большинство разработчиков, скорее всего, представляют себе архитектуру только в приложении к конкретному проекту, т.е. можно часто услышать от них «архитектура ПО», однако это лишь малая часть того, что входит в общее понятие. Условно можно разделить глобальное понятие на несколько частей, от общего к частному. Можете представить их в виде пирамиды:

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

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

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно перевести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

Получается, что есть 3 вида/уровня архитекторов:

• Enterprise (EA)
• Solution (SA)
• Infrastructure (IA)

В аспекте разработки, далее будем рассматривать задачи и ответственности EA и SA, не забывая впрочем, о важной роли IA.

Отличия Enterprise Architect от Solution Architect

Если совсем кратко, то:

• Enterprise – что делать
• Solution – как делать

К кругу вопросов и задач, которые стоят перед EA можно отнести:

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

Вопросы перед Solution Architect более знакомы простым разработчикам, например:

• Выбор фреймворков для работы;
• Представлений пользователю;
• Контроль за развитием приложения;
• Решение спорных моментов у разработчиков.

Различия графически можно представить следующим образом:

^[1]

EA разрабатывает глобальный план работы приложения, взаимодействия его с другими приложениями. SA работает над конкретным ПО. При этом EA постоянно следит за тем, как именно развивается приложение и может вносить коррективы в концептуальные части приложение.

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

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

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

Уровни ответственности и влияния

^[2]

На данной, схеме показаны зависимости и отношения между разными уровнями архитектурного планирования. Влияние их друг на друга. Комментировать не стоит, я думаю.

Возможные артефакты enterprise architecture:

• Проектные планы
• Отображение бизнес-процессов на системы
• Бизнес-процессы
• Организационная структура
• Технологическая архитектура интеграции систем
• Структуры данных
• Топология развертывания систем и их компонент
• Топология сети и подключения оборудования
• Физическое размещение систем
• Реестры систем и оборудования
• Функциональные системы

Связь между ними на фотографии ниже. Извините за качество.

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

^[3]

Работа архитекторов

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

Определенных средств для разработки и контроля никто не называл. Так или иначе, используется компиляция средств из Visio, SharePoint, Wiki.

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

Из дополнительного материала можно порекомендовать TOGAF9 и блог Nick Malik ^[4].

Автор: VioletTape